For decades, it has been common practice to represent the year in data processing systems using two digits instead of four. Thus, the year "1995" is represented (and often stored) using the two last digits "95." This practice minimized expensive memory space and data entry time.
In the Year 2000 ("Y2K"), many systems will interpret the two digit year "00" to mean the year 1900, an obviously undesirable result of dealing with dates represented using only two digits. This problem is acute, and if an organization does not take necessary steps to make its systems "Year 2000 compliant," then it may face severe business consequences. For example, records of credit card payments, IRS tax refunds and even air-traffic control systems that keep planes safely separated may be disrupted. A "Year 2000 compliant" system is one which can correctly operate with dates belonging to both the 20th and 21st centuries. Due to its scope and the time constraint, the Y2K "bug" fixing poses formidable challenges. The cost of fixing the Y2K problem worldwide is estimated to be in the hundreds of billions of dollars.
Considering the time and the resources required, automated tools will have a significant role to play in efforts to make applications Y2K compliant. Generally, Y2K conversion efforts involve a two-step process: first, the system must be converted to make it Y2K complaint and second, the system must be thoroughly tested to ensure that it has been correctly converted. The second "debugging" step often may turn out be more time-consuming and costly than the actual conversion step itself. While numerous automatic code/system conversion tools are now available for the first step of Y2K conversion efforts, a testing discipline and automated testing tools seem to be universally lacking for the second step.